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Network Time Protocol Version 4 (NTPv4) Extension Fields 
Abstract 


The Network Time Protocol version 4 (NTPv4) defines the optional 
usage of extension fields. An extension field, as defined in RFC 
5905, is an optional field that resides at the end of the NTP header 
and that can be used to add optional capabilities or additional 
information that is not conveyed in the standard NIP header. This 
document updates RFC 5905 by clarifying some points regarding NTP 
extension fields and their usage with Message Authentication Codes 
(MACs). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7822. 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The NIP header format consists of a set of fixed fields that may be 
followed by some optional fields. Two types of optional fields are 
defined: Message Authentication Codes (MACs), and extension fields as 
defined in Section 7.5 of [NTPv4]. 


If a MAC is used, it resides at the end of the packet. This field 
can be either 24 octets long, 20 octets long, or a 4-octet 
crypto-NAK. 


NTP extension fields were defined in [NTPv4] as a generic mechanism 
that allows the addition of future extensions and features without 
modifying the NTP header format (Section 16 of [NTPv4]). 


The only currently defined extension fields are those fields used by 
the Autokey protocol [Autokey] and the Checksum Complement [RFC7821]. 
The Autokey extension field is always followed by a MAC, and 

Section 10 of [Autokey] specifies the parsing rules that allow a host 
to distinguish between an extension field and a MAC. However, a MAC 
is not mandatory after an extension field; an NTPv4 packet can 
include one or more extension fields without including a MAC. This 
behavior is specified in Section 7.5 of [NTPv4] and in [Err3627], and 
is further clarified in this document. 


This document updates [NTPv4] (RFC 5905) by clarifying some points 
regarding the usage of extension fields. These updates include 
changes to address errors found after the publication of [NTPv4] with 
respect to extension fields. Specifically, this document updates 
Section 7.5 of [NTPv4], clarifying the relationship between extension 
fields and MACs, and defining the behavior of a host that receives an 
unknown extension field. 
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2. Conventions Used in This Document 
2.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KEYWORDS]. 


2.2. Terms and Abbreviations 
MAC Message Authentication Code 
NTPv4 Network Time Protocol version 4 [NTPv4] 


3. NTP Extension Fields - RFC 5905 Update 
This document updates Section 7.5 of [NTPv4] as follows: 
OLD: 


7.5. NTP Extension Field Format 


In NTPv4, one or more extension fields can be inserted after the 
header and before the MAC, which is always present when an 
extension field is present. Other than defining the field format, 
this document makes no use of the field contents. An extension 
field contains a request or response message in the format shown 
in Figure 14. 


0 1 2 3 
OT 2 3 A 6 EB OO 23 AO OP BOO. TL 23 AO OT 88 9. OL. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Field Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Value 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Padding (as needed) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 14: Extension Field Format 


All extension fields are zero-padded to a word (four octets) 
boundary. The Field Type field is specific to the defined 
function and is not elaborated here. While the minimum field 
length containing required fields is four words (16 octets), a 
maximum field length remains to be established. 
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The Length field is a 16-bit unsigned integer that indicates the 
length of the entire extension field in octets, including the 
Padding field. 


NEW: 
7.5. NTP Extension Field Format 


In NTPv4, one or more extension fields can be inserted after the 
header and before the MAC, if a MAC is present. 


Other than defining the field format, this document makes no use 
of the field contents. An extension field contains a request or 
response message in the format shown in Figure 14. 


0 1 2 3 
OL Z 34.3) 6. 289 OL 2. Be 4. 506-7 8: 9 Od. 23) 4A 5 6 7 8. 9 Oe LT 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Field Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Value 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Padding (as needed) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 14: Extension Field Format 


All extension fields are zero-padded to a word (four octets) 
boundary. 


The Field Type, Value, and Padding fields are specific to the 
defined function and are not elaborated here; the Field Type value 
is defined in an IANA registry, and its Length, Value, and Padding 
values are defined by the document referred to by the registry. 

If a host receives an extension field with an unknown Field Type, 
the host SHOULD ignore the extension field and MAY drop the packet 
altogether if policy requires it. 


While the minimum field length containing required fields is 
four words (16 octets), the maximum field length cannot be longer 
than 65532 octets, due to the maximum size of the Length field. 


The Length field is a 16-bit unsigned integer that indicates the 


length of the entire extension field in octets, including the 
Padding field. 
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7.5.1. Extension Fields and MACs 
7.5.1.1. Extension Fields in the Presence of a MAC 


An extension field can be used in an NTP packet that includes a 
MAC -- for example, as defined in [Autokey]. A specification that 
defines a new extension field MUST specify whether the extension 
field requires a MAC or not. If the extension field requires a 
MAC, the extension field specification MUST define the algorithm 
to be used to create the MAC and the length of the MAC thus 
created. An extension field MAY allow for the use of more than 
one algorithm, in which case the information about which algorithm 
was used MUST be included in the extension field itself. 


7.5.1.2. Multiple Extension Fields with a MAC 


If there are multiple extension fields that require a MAC, they 
MUST all require the use of the same algorithm and MAC length. 
Extension fields that do not require a MAC can be included with 
extension fields that do require a MAC. 


An NIP packet MUST NOT be sent with two or more extension fields 
that require a MAC with different algorithms. 


If an NTP packet is received with two or more extension fields 
that this receiver recognizes and those fields require a MAC with 
different algorithms, the packet MUST be discarded. 


7.5.1.3. MAC in the Absence of an Extension Field 


A MAC MUST NOT be longer than 24 octets if there is no extension 
field present, unless a longer MAC is agreed upon by both client 
and server. The client and server can negotiate this behavior 
using a previous exchange of packets with an extension field that 
defines the size and algorithm of the MAC transmitted in NTP 
packets. 
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4. 


7.5.1.4. Extension Fields in the Absence of a MAC 


If a MAC is not present, one or more extension fields can be 
inserted after the header, according to the following rules: 


o If the packet includes a single extension field, the length of 
the extension field MUST be at least 7 words, i.e., at least 
28 octets. 


o If the packet includes more than one extension field, the 
length of the last extension field MUST be at least 28 octets. 
The length of the other extension fields in this case MUST be 
at least 16 octets each. 


Security Considerations 


The security considerations of time protocols in general are 
discussed in [SecTime], and the security considerations of NTP are 
discussed in [NTPv4]. 


Distributed Denial-of-Service (DDoS) attacks on NTP servers involve 
flooding a server with a high rate of NIP packets. Malicious usage 
of extension fields cannot amplify such DDoS attacks; such malicious 
attempts are mitigated by NTP servers, since the servers ignore 
unknown extension fields (as discussed in Section 3) and only 


respond, if needed, with known extension fields. Extension fields 
from incoming packets are neither propagated by NTP servers nor 
included in any response. NTP servers create their own extension 


fields if needed for a response. A large number of extension fields 
should be flagged by an NTP server as a potential attack. Large 
extension field sizes should also be flagged, unless they are 
expected to be large. 


Middleboxes such as firewalls MUST NOT filter NTP packets based on 
their extension fields. Such middleboxes should not examine 
extension fields in the packets, since NTP packets may contain new 
extension fields that the middleboxes have not been updated to 
recognize. 
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